Application Security is a serious problem which significantly inhibits the ability to interface enterprise systems. Controlling users has spawned entire software industries. Some of the problems engendered include:
With reference to FIG. 1, a diagram of a conventional trust architecture is illustrated. The employees operate computers that use web browsers 101 to obtain information. The company can have a protected resource server 105 that is accessible to employees. However to prevent unauthorized access, a policy enforcement point 103 is placed between the web browser 101 and the protected resource server 105. The policy enforcement point 103 can be controlled by a policy decision point 107 that determines requirements for allowing access to the protected resource server 105.
Provisioning Users. In a large organization, the user population is constantly changing as employees come and go and change roles within the organization. It becomes a full time job simply to administer these users.
Multi Factor Authentication. Username and password authentication has been discovered to be easily subject to compromise. Consequently, many vendors offer additional authentication techniques to make it more difficult to penetrate systems containing proprietary information.
Single sign on. In an organization having multiple systems, each users finds themselves with multiple user names, one for each system he needs to access. Users find this inconvenient and frequently forget their assigned user names. Single-sign provides a solution. Single sign is also referred to as federated security. In a federated security model, a separate authentication system called an “Identity Provider” is introduced. An identity provider defines a user name for each user and offers an authentication procedure by which a person with knowledge of a user name can prove their identity (often this is nothing more than by entering a private password). Many enterprise systems can rely on one identity provider to define user identities. For the user, the same username can grant access to many systems. While this approach solves the problems of users forgetting their usernames, but it has inherent flaws.
Federated security multiplies the severity of security breaches enormously. In a non-federated world, stealing a username/password allows the thief access to one system. In a federated world, the same theft gives the thief access to many systems.
User authentication occurs once in a login process. Yet security requirements are driven by the specific data/functionality that the user intends to access. A system often contains a mix of sensitive and non-sensitive data and at login time it is not known which specific data the user wishes to access. Thus the authorization procedure used at login is too severe for some user activities and too lax for others. A more truly secure system should authorize users only after they have requested a specific resource when the true security requirement is known.
Different systems often have different security requirements. A federated approach forces every system into a one-size fits all approach. If authorization is enforced at login time by the host system, then the owners of the second system have a dilemma: either they accept the security mechanisms of the host system, or they demand that they are changed to meet their own requirements. They have no way to impose security requirements that only apply when data or functionality sourced from the second system are accessed.
The cost of implementing security and the liability for breaches is concentrated in the organizations that control the applications. As a consequence, application owners may be either unwilling to invest enough to protect others' security and privacy, unwilling to make information available due to liability concerns, or both.
Individuals (both users and the people who are the subjects of records within enterprise systems) are forced to trust applications and the organizations that control them, whether they want to or not. There is no way to monitor how security and privacy is protected that doesn't depend upon the trustworthiness of the application owners.
The result is a world of fragmented data and failure-prone security which creates a crisis of trust. Users become unwilling to share information or use applications. Applications and organizations are often unwilling to share information with one another. This friction undermines the flow of information and the ability to offer intelligent or personalized services. Large-scale exchange of privacy-sensitive information between unaffiliated organizations becomes difficult and expensive. This has widespread consequences in most industries—but negative consequences are especially prevalent in healthcare, an industry that relies upon the flow of privacy-sensitive information.
Virtual Applications. The world wide web acts as a platform for the development of virtual documents. E.g., a user may create a web site that appears as though it were a single document to the user, yet it is composed of many individual pieces sourced transparently from many different locations. This concept allows for reuse of information and dynamic assembly of interesting new web sites from existing pieces.
Service-oriented application (SOA) architectures have tried to accomplish something similar, albeit more limited. for applications. In a service-oriented architecture, application functionality can be published as a service, and then consumed by another application which uses that functionality and may present it to users. SOA services are published as an application programmer's interface (API). An API is a set of functions that can be invoked by another application. Therefore in an SOA architecture, it is the responsibility of the consumer of a service to develop a user interface through which an end user can experience and consume a service. In an SOA architecture, a collection of services register with a directory, and an application programmer may then develop an application by picking services to use from the directory and then authoring code to integrate them and develop user interface for them.
Portal/portlet architectures are another step towards developing virtual applications. In a portal application, small applications called portlets are published as web applications. Unlike an SOA service, a portlet publishes a user interface rather than Application programmer's interface (API). POrtlets can be integrated into larger units of functionality within a portal.
Both portlet and SOA architectures are attempts at developing applications that can easily be assembled from predefined pieces. However, both are limited. In both cases, the decisions of which services or which portlets to embed are defined in advance by the application programmer developing the portal.
The worldwide web provides a platform for loose integration between applications by providing general mechanisms for publishing information (web servers), finding information (search engines), describing content (markup languages, AJAX Javascript, etc.) and viewing content (web browsers). However, the web provides little help with application security and the challenge is larger and more serious on the internet where some users will be actively malicious. How can the publisher of a piece of information, assert its security control requirements regardless of where that information is eventually used? Without such assurances, owners of confidential information are unwilling to publish it widely, and even if they do publish it with a web-based application, they are not willing to share it within the context of external applications they do not control. Without this sharing, many opportunities for synergy are lost and confidential information is duplicated in many places unnecessarily.
The Resilient Trust Network addresses the problems of application integration and user security on a distributed network such the worldwide web to allow publishing privacy sensitive information on an insecure network such as the internet. Similar to the worldwide web mechanisms already referenced, the Resilient Trust Network provides new functions in areas where the web has been weak as follows:
Discovery and syndication of trust services, definition and publishing of trust requirements, provision of user interface for viewing information (Resilient Access Server).
Resolution of trust requirements for each source of information or policy, provision of anonymity for all trust related operations, (Resilient Trust Server).
The addition of these servers to the conventional worldwide web mechanisms allows the Resilient Trust Network to provide a trust environment integrated with the current web so that security and integration for large-scale application systems can be provided in a unique and productive manner not available through the conventional means described above.
In an embodiment, a Resilient Trust Network (RTN) is a set of servers that provide: an application integration platform for developing and publishing services and user interface for services, building derived services, subscribing to services, and embedding services into host applications, and building composite applications composed from multiple diverse services. The RTN can also provide a platform for defining security requirements and accessing shared trust services that implement those requirements for services regardless of where or how those services are used.
The RTN allows an application programmer to create and publish services that provide access to resources. A service makes available either data or application functionality in a form that can be embedded into other applications called host applications. For example, in the medical application domain, a service might provide patient prescription histories which could then be embedded into a hospital's EMR where a treating physician can view them. The specification discloses the use of the RTN in a medical application domain. However, in other embodiments, the RTN can be used in any other technology or information field.
Services are defined using an access server. An access server is a customizable software component that can be linked to any backend system to handle the details of preparing that functionality for publication as a service. An access server can perform various functions including: publishing a public interface for a service, mapping calls made to the public interface into the private interface of a back end system, defining and serving a user interface for the service, defining and serving a data-stream for the service (for example, an XML or JSON document). In some embodiments the access server can transform data provided by the backend system in a proprietary format into a data format usable by external applications. This format conversion allows data to be easily shared by different applications. The access server can also formulate a credential request to the trust server to validate the user prior to releasing data. This allows the RTN to provide any security measures required by an application or service. The access server can also subscribe to other services and transforming the data structure or user interface (UI) of subscribed services for presentation within the UI of a host application. Services may be merged and composed. For example, a service may source data from two other services A and B, transform that data or define a new user interface for this data, and then publish it as a new service C ready to be embedded into host applications. This allows the host application to integrate various UIs from different services to a single host application UI.
The inventive system can be configured with a high level of security. An application developer can implement security for a service by invoking Trust services. A service invoking a trust service is referred to as a relying party. Trust services will enforce security requirements automatically regardless of the host application where the relying party has been embedded. This facility enables an application developer to publish confidential information securely since he can guarantee enforcement of security policies as if he controlled the host application.
The access server also allows application programmers to embed services into host applications. A host application is any application that subscribes to one or more services. The network provides a directory of published services and their interfaces. Using an access server, a host application may subscribe to any number of services found in the directory, configure an interface to invoke the subscribed service and customize the results returned by the service. Many services already publish a user interface, but an application host is free to modify that interface or develop another using its access server.
One host application may embed any number of services. Services may be embedded at design time by a programmer or may be embedded conditionally. When services are embedded conditionally, the choice of the service displayed to the user is made after information some information has been gathered from the user at run time. For example, a system displaying medical records might allow the user to select a patient, and then only bind in a specific source of patient data after finding a source that contains data about the given patient.
The host application can modify the user interface of services it uses or subscribes to. Thus, the RTN provides a flexible platform for developing host applications via composition using published services. Since each service come bundled with application security, the host application need not modify its own security mechanisms to cater to the requirements of the service(s) consumed.
In an embodiment, the RTN provides a protocol for invoking, interacting with and embedding trust services. A trust service is any application that serves to authenticate user identity, personal attributes or user privileges used prior to allowing access to protected resources or any application that documents completed user interactions with protected resources. Examples of trust services include an OpenID identity provider, a phone authentication service, a records retention service, and an audit log that records user interactions with protected data resources. The RTN provides access to many trust services and enables a relying party to combine them in arbitrary ways.
Relying parties interact with trust services through a trust server which is responsible for orchestrating and optimizing interactions with trust services using a trust protocol. In an embodiment, a relying party sends a credential request to the trust server which describes the set of credentials that will be required to obtain the credential. The Trust server in turn messages the required trust services, passing them only that part of the credential request they are required to process. Trust services process the credential requests. In some cases, the processing may involve interacting with the user. If the required information is provide the trust service will issue a credential to indicate approval. For most credential requests, multiple trust services are required. As the required information is obtained, the trust server caches the responses until all required credentials have been gathered. The trust server issues final authorization to allow the user interaction to proceed after all of the required credentials have been obtained. The trust server can also include a trust history that stores previously earned credentials in one or more sessions so that the number of authentications required of the user is minimized.
The RTN provides a development environment for authoring trust services and can be used in a wide variety of applications and industries. Trust services frequently are linked to a back end system. Trust credentials served by a trust service are published to a directory to make them usable by services and hosts. The RTN trust service development platform also supports creation of policy trust services, and compound and syndicated trust services.
A policy service can be a trust service that defines a reusable credential request that can be shared across organization. For example, a governmental authority might operate a policy service to define a set of access policies as a credential request that complies with state law. Application services could then simply subscribe to the policy service rather than creating their own complex credential request and have assurance their security will comply with state law.
A compound trust service can combine individual trust services into a more powerful whole. For example, in an embodiment, a compound trust service might combine a Lightweight Directory Access Protocol (LDAP) database acting as an identity provider with a phone authentication service. When the user submits a user name recognized by the LDAP database, the trust service would query the LDAP database for the user phone number. The phone number could then be forwarded to a phone authentication service which would call the user and compare the answering person's voice to a stored voice print. The compound trust service would only grant a credential to the user after the voiceprint match was confirmed.
A trust syndicate can be a single trust service that acts as a common front end to multiple back end trust services. When the syndicated service is invoked, it delegates action to one or more of its members, depending on the content of the request it receives. The trust syndicate enables a higher degree of reliability and reusability in trust. It enables anonymous trust verification. In an embodiment, the relying party invoking a trust syndicate may not ever know the actual trust service verifying the identity of the user. Some entities may only be willing to offer their trust services in an anonymous fashion. Because the inventive system is extremely flexible, it can provide fungibility between multiple potentially dissimilar trust services.
In an exemplary embodiment, the following process steps describe the system's typical interactions. A User can first invokes a host application via a web browser. The host application provides a user interface allowing a user to request access to a protected resource served by a service. A protected resource is often, but not always, a unit of data. It can be anything from an XML document, a binary file, a collection of database records; an individual attribute or a fragment of HTML. The service can retrieve the protected resource from its back-end data server and makes a credential request to the trust server including a Credential expression. The credential expression can include a specification of which trust services and policies must be satisfied in order for authorization of the credential to be granted to the requestor. The Trust Server forwards appropriate credential expressions to the needed trust services. The trust services can each perform a validation, potentially via some user interaction. If the validation is correct, the trust services reply to the trust server with credentials. When all required credentials are present, the Trust Server returns approval to release the protected resource to the trust service. The trust service can then provide the protected resource to the host application. The host application serves the protected resource to the user's web browser. The inventive system is extremely flexible and can be utilized in various industries and applications.